Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: TypeError on creating properties on immutable objects #671

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

novikovfred
Copy link

@novikovfred novikovfred commented Jun 7, 2024

fix #670

Copy link

changeset-bot bot commented Jun 7, 2024

⚠️ No Changeset found

Latest commit: 69395d2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@novikovfred novikovfred changed the title issue-670: fix TypeError on changing immutable objects #670: fix TypeError on changing immutable objects Jun 7, 2024
@novikovfred novikovfred changed the title #670: fix TypeError on changing immutable objects #670: fix TypeError on creating properties on immutable objects Jun 7, 2024
@novikovfred
Copy link
Author

@edmundhung review pls

@novikovfred novikovfred changed the title #670: fix TypeError on creating properties on immutable objects fix: TypeError on creating properties on immutable objects Jun 14, 2024
Comment on lines +138 to +161
function canAddProperty(
obj: Object | Array<unknown>,
property: string | number,
): boolean {
const propertyStr =
typeof property === 'number' ? property.toString() : property;
if (Object.prototype.hasOwnProperty.call(obj, propertyStr)) {
const descriptor = Object.getOwnPropertyDescriptor(obj, propertyStr);
if (descriptor && !descriptor.writable) {
return false;
}
}
if (!Object.isExtensible(obj)) {
return false;
}
if (Object.isSealed(obj) && !(propertyStr in obj)) {
return false;
}
if (Object.isFrozen(obj) && !(propertyStr in obj)) {
return false;
}
return true;
}

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanna understand better the impact of this change. Can you explain a bit more what each condition is trying to handle?

Copy link
Author

@novikovfred novikovfred Jun 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As i mentioned in #670 (we can reproduce with FormData as well)currently we can get TypeError if we will try to assign property on immutable object.
Since we validate and get data from those parameters that can be passed by users, including frauders. We wouldn't want to get errors in runtime error because of a user who enters intentionally incorrect data.
If frauder will try to create any param with immutable type at first(example: param=value) and then will try to add some property to it (example: param.child=value) we will get a TypeError.
Of course, I can handle the error, but I would like not to get errors in the application's runtime.

If we wanna support changes of property values i can rework my PR a bit.

With these change I want to check properly if we can add a property to a given object.

  Check if the property already exists and is not writable
  if (Object.prototype.hasOwnProperty.call(obj, propStr)) {
    const descriptor = Object.getOwnPropertyDescriptor(obj, propStr);
    if (descriptor && !descriptor.writable) {
      return false;
    }
  }

  Check if the object/array is extensible, isExtensible returns a value that indicates whether new properties can be added to an object.
  if (!Object.isExtensible(obj)) {
    return false;
  }

  Check if the object/array is sealed and property doesn't exist, isSealed returns true if existing property attributes cannot be modified in an object and new properties cannot be added to the object.
  if (Object.isSealed(obj) && !(propStr in obj)) {
    return false;
  }

  Check if the object/array is frozen and property doesn't exist, isFrozen returns true if existing property attributes and values cannot be modified in an object, and new properties cannot be added to the object.
  if (Object.isFrozen(obj) && !(propStr in obj)) {
    return false;
  }

@confix
Copy link

confix commented Aug 20, 2024

Actually the check makes perfect sense to me. We were bitten by that today as well.

Someone updated a fieldset (object) via form.update with a string value instead of an object.
Afterwards we want to set a property of the mentioned fieldset via a regular input field and the error occurs.

// state: { fieldset: { property: "aValue" }}
form.update({ name: "fieldset", value "a string" })
// state: { fieldset: "a string" }

// a change to the input below crashes with the same error
<input name="fieldset.property" />

We should report a warning as long as we're in development, though. We could end up in the very same situation by simply having a bug in our application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Found TypeError: Cannot create property on string
3 participants